Described below is a method for verifying the authenticity of messages which are exchanged between a mobile node and a home agent according to a mobile Internet Protocol. Internet protocol IPv4 was developed for wired communication with fixed-location computers and switching nodes. To allow devices such as laptops and PDAs (Personal Digital Assistants) to switch from one computer network into another for example and in doing so to retain a fixed IP address, the network protocol “IP mobility Support for IPv4”, abbreviated to “Mobile-IP” was drafted by the “Internet Engineering Task Force” (IETF). Mobile-IP is described in the “Request For Comments” (RFC) 3344 and applies as a standard for Internet connections with mobile subscribers.
In Mobile-IP a mobile node refers to a computer or router which changes its access from one network to another network. Home agents are routers which are connected in the home network of the mobile node and which administer the location information of the mobile node. A foreign agent is a router which provides the routing services to the foreign network for the mobile node and takes over the forwarding of data packets from the home agent to the mobile agent.
If a mobile node discovers that it has been connected to a foreign network it requests a care-of address in the foreign network. The care-of address is determined from the advertisement of the foreign agent (foreign agent care-of address) or via DHCP (co-located care-of address). The mobile node registers with its home agent using the new care-of address. The data packets arriving at the home agent are then sent on to the mobile host by IP-to-IP encapsulation. After its return to the home network the mobile node establishes contact with its home network and registers itself there.
When a foreign agent is used the following operations are necessary for registration: The mobile node transfers a registration request with the address of its home agent to the foreign agent. The latter forwards the registration request to the home agent. Thereafter the home agent sends a registration reply to the foreign agent which either accepts or rejects the registration. Finally the foreign agent transfers the registration reply to the mobile node. Without a foreign agent only two steps are required for registration: First the mobile node sends a registration request to the home agent. Subsequently the home agent replies with a registration reply to the mobile node.
Since the mobile node notifies the home agent in the registration request of its current care-of address, i.e. the address under which it is to be reached in the foreign network, this address must be protected against manipulation. If for example an attacker were to modify the care-of address in a registration request the home agent no longer sends all data packets to the mobile node, but to the address specified by the attacker. The authenticity of the registration messages must be guaranteed, their contents may not be changed nor may their sender be falsified.
To protect the authenticity so-called Mobility Security Associations (MSA) are provided between the two communication partners. The communication partners are mostly the home agent and a mobile node, with mobility security associations also existing between foreign agent and home agents or between foreign agent and mobile node. A number of different mobility security associations can exist between the communication partners in each direction, with in practice only a single mobility security association being used for both directions. Mobility Security Associations MSA are collections of security relationships between the communication partners and specify which cryptographic method and which key are to be used for protecting the authenticity. The individual security relationships of a mobility security association are identified by a “Security Parameter Index” (SPI).
The cryptographic methods of the security relationships include an authentication algorithm and a replay protection style in each case.
HMAC-MD5 is provided as the standard authentication algorithm, which calculates on the basis of the MD5 algorithm a “Message Authentication Code” (MAC), meaning a hash value with a secret key covering the message to be protected. If the message is modified or another key is used, the Message Authentication Code MAC changes when it is calculated again and manipulations or sender falsifications can be rejected. As well as HMAC-MD5 other authentication algorithms can also be used.
Replay protection is used for protection against old registration requests being replayed. With replay protection with time stamps the time of day is inserted into the message by the sender and a check is made by the recipient that the message is not older than a prespecified time. With replay protection with nonces (number used only once) a new random number is inserted into each message to the recipient from the sender. The sender then checks whether the recipient inserts the same number into its next message to the sender. Other replay protection styles can also be used. The time stamps and nonces or the values created by other replay protection styles are entered by the sender into an identification field of the registration messages and checked by the recipient.
To be able to authenticate a message, Mobile-IPv4 makes provision for the sender to append an authentication extension to the message which includes the Security Parameters Index SPI and the Message Authentication Code MAC covering the part of the message to be protected. An authentication extension between mobile node and home agent is referred to as the “Mobile Home Authentication Extension” (MHAE). The recipient checks the authenticity by accessing the Mobility Security Association MSA identified by the Security Parameters Index SPI and from it determines the authentication algorithm and replay protection style to be used. To do so the recipient computes the Message Authentication Code MAC and verifies that the received result matches the Message Authentication Code MAC in the received message. To protect against replays of old messages, the replay protection style values in the identification field of the registration messages are also checked.
Since different authentication algorithms and replay protections styles can be used with Mobile-IP, the communication partners must agree about the authentication algorithm and replay protection style to be used.
One option for doing this involves defining the authentication algorithm and replay protection style to be used beforehand and configuring the mobile node and the home agent accordingly. However this procedure has the following disadvantages: In a large network with many mobile nodes and a number of home agents manual configuration of all communication partners is very time consuming. This applies both to the initial configuration and also to the case in which weaknesses are discovered in the configured cryptographic method and this has to be replaced in all communication partners. Furthermore it is not possible, if the cryptographic methods supported by the mobile node or the home agent are unknown, e.g., for roaming in 3GPP (Third Generation Partnership Project) WLANs (Wireless Local Area Networks), to determine the supported cryptographic methods of the two communication partners within a short period, to define a suitable shared authentication algorithm and replay protection style and to configure the two communication partners accordingly.
An improvement to overcome these disadvantages involves the network selecting the cryptographic method to be used by the communication partners. In RFC 3957 “Authentication, Authorization and Accounting (AAA) Registration Keys for Mobile IPv4” the Mobility Security Associations MSA between the mobile node and its home agent or the Foreign Agent are derived from the “AAA Security Association” between the mobile node and its Home AAA Server. The authentication algorithm and replay protection style are transmitted in a “Key Generation Extension” of the registration message from the AAA server to the mobile node and the home agent. A similar method with a Diameter AAA servers is described in the RFC 4004 “Diameter Mobile IPv4 Application”. The method allows the network to determine the cryptographic method. The disadvantage however is that in generally it is not known to the network which authentication algorithms and replay protection styles are supported by the mobile node. Thus for example an older mobile node which does not support the newest cryptographic method prescribed by the network cannot communicate with the latter although the mobile node perhaps supports an older method still accepted as secure by the network.
A further improvement of this situation involves not defining the cryptographic method on one side but negotiating it between the communication partners. A method is known from RFC 3329 “Security Mechanism Agreement for the Session Initiation Protocol (SIP)” in which a client sends a list of supported cryptographic methods to a server. The server then sends the client a challenge with a list of the cryptographic methods which it supports. The client selects from the common methods the method with the highest preference. To avoid an attacker modifying the list of and thus pretending for example that only cryptographically-weak methods are supported by the server and the communication partners subsequently agreeing on a corresponding weak method, the list must be transmitted once more protected. The client thus activates the selected cryptographic method and sends the server the list with the methods supported by the server. The server checks the authenticity of the list to insure that the original list has not been modified. A further negotiation mechanism is known from the “Internet Key Exchange” (IKE, IPsec-IKE). The disadvantage of this method is however that it cannot be used for mobile IP since the first message must be transferred unprotected but mobile IP demands an authentication protection right from the first message transmitted. A further disadvantage is that the list with the supported cryptographic methods has to be transmitted twice.